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METHOD AND SYSTEM FOR ESTABLISHING 
A CREDIT CARD TRANSACTION PROCESSING MERCHANT ACCOUNT 



This application claims priority benefit of United States Provisional Application 
5 Serial No. 60/248,407 filed on November 14, 2000, which is incorporated herein by 
reference in its entirety. 

BACKGROUND OF THE INVENTION 

The present invention relates to a method and system for rapidly establishing 
credit card merchant accounts (MAs) whereby merchants can begin processing credit 
10 card transactions or exchanging other data pertinent to such transactions nearly 
instantaneously after applying for a merchant account. Once the MAs are established, 
% credit card transactions may be processed in any sales environment, including sales over 

Via? 

hi 

Jn the Internet and sales at conventional bricks-and-mortar establishments. 

Electronic commerce over global computer networks such as the Internet is 



Ml 5 expanding rapidly. It has been estimated that worldwide Internet commerce will reach 
N J $1.44 trillion by the year 2003. The number of so-called ".com" businesses which sell 



their wares over the Internet is exploding. In fact, software has been developed that 
allows a start-up e-commerce merchant to establish an Internet presence, display products 
and prices and generally conduct business over the Internet in less than an hour. Also, 
20 Internet merchant host services have been established which provide the infrastructure for 
supporting on-line businesses so that the e-commerce merchant need not even supply the 
computer hardware and server software for establishing an electronic storefront. 

One impediment to quickly establishing an on-line business presence is 
establishing a method of receiving payment for the goods or services being offered for 
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sale over the Internet. Because the parties to Internet transactions are remote from one 
another, tendering cash or offering checks and other traditional forms of payment is 
generally impractical. Credit card transactions therefore have become the de facto 
standard method of tendering payment over the Internet. But, before an on-line merchant 
can begin accepting credit card payments, the merchant must first establish a credit card 
merchant account (MA). Of course, the same applies to merchants operating out of 
conventional bricks-and-mortar establishments. 

Each MA includes a merchant identification number (MID), a terminal 
identification number (TID), and a gateway identification number (GID). The MID 
uniquely identifies the merchant, and the TID uniquely identifies the merchant location 
where a particular transaction occurs. In general, a merchant will have but a single MID, 
but may have multiple TIDs if the merchant is doing business from multiple locations, 
including any combination of different Internet addresses and bricks-and-mortar sites. 
Merchants doing business exclusively over the Internet or exclusively at a single bricks- 
and-mortar location, however, will likely have but a single TID. The GID identifies an 
Internet gateway between the public Internet and a private network of banks, independent 
sales organizations (ISOs), acquirer banks (ACQs) and processing centers for processing 
credit card transactions. 

Using traditional methods, applying for and establishing an MA can take from a 
few days to several weeks. This is a significant burden to the start-up on-line merchant. 
During the period when the merchant is waiting for the MA the merchant is effectively 
prevented from conducting business, possibly losing revenue that may be necessary for 
the business to survive and grow. Thus, there is an acute need for a method of 
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establishing credit card processing MAs for on-line merchants. By the same token, 
conventional bricks-and-mortar merchants will also benefit from an expedited method for 
establishing credit card MAs. The present invention provides such a method, as well as a 
system for implementing the inventive method. 

Before describing the method and system of the present invention, however, it is 
first necessary to describe the on-line credit card transaction process and the elements 
necessary to establish an MA. Fig. 1 shows a schematic diagram of a typical set-up for 
processing credit card transactions over the Internet. An on-line merchant is shown at 12. 
Merchant 12 may be independently operating its own web server, supporting its web 
presence with its own hardware and software, or the merchant may be setting up its 
online business through a merchant host server 14. (Since the merchant host server 14 is 
optional, it is shown in dashed lines in the figure.) The Internet is shown as an 
amorphous cloud 22 of interconnected networks and packet switched routers and 
computers, all implementing standard Internet protocols as is known in the art. 

Also shown connected to the Internet 22 are an on-line customer 18, an 
independent sales organization (ISO) 20 or, alternatively, acquirer bank (ACQ) 21 and a 
payment gateway 16. The payment gateway 16 is in turn connected to a credit card 
processing front-end system or authorization center 24 which is connected to a back-end 
settlement network 26. The merchant's acquiring bank 28 (which may be different from 
ACQ 21 but often will be the same entity), a credit card issuing bank 30, and the ISO 20 
are connected through the back-end settlement network 26. 

During the course of an Internet transaction, a payment page is sent from the 
merchant 12 to the on-line customer 18 and displayed by the customer's Internet browser. 
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The customer enters his or her credit card number, the expiration date of the card, and the 
purchase amount in the designated fields of the payment page and selects a transmit 
function typically activated by mouse clicking on a software button displayed on the 
payment page. The MID, TID and GID associated with the merchant's MA are 
5 embedded within the instructions for displaying the payment page. 

The browser transmit function sends the transaction data, preferably through a 
secure socket layer (SSL), including the credit card number, expiration date, the MID and 
the TID, to an Internet gateway 16 designated by the GID embedded within the payment 
page. The gateway directs the transaction to front-end processing center 24, also 
10 identified by the GID. The front-end processing center verifies that the card has not been 

v3 

reported lost or stolen, that the transaction is within the customer's credit limit, and may 
?1 perform other security checks. Typically, this is accomplished by contacting a transaction 
g ' authorization agent associated with the brand of the credit card, for example, VISA, 

y, 

H MasterCard, American Express, Discover, and the like. Provided that all of the data and 
"Pi 5 security checks pass muster, the transaction is approved. A message, usually including 

f* v 3 

^ an approval code, is sent back to the merchant through the payment gateway 16 and over 
the Internet 22. At this point the transaction is considered to be authorized (or 
"captured"). 

Once the transaction data reaches the front-end system 24, the transaction 
20 proceeds in the conventional manner. The front-end processing center accumulates 
transactions throughout each business day. At the end of each day the front-end 
processing center batches the captured transactions to the various acquiring banks 
associated with the merchants whose transaction have been accumulated. The proper 
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acquiring bank for a particular transaction may be identified from the MID and TID 
associated with the transaction. 

Once the acquiring bank receives the batched transactions, the bank performs an 
automated clearinghouse function on the transactions (ACH). As part of the ACH, the 
5 acquiring bank batches transaction files to each of the card issuing banks whose credit 
card holders have entered transactions captured by the front-end processing center and 
forwarded to the acquiring bank. The issuing banks post the transactions to their 
cardholders' accounts to be listed on the cardholders' monthly statements. The issuing 
bank then transfers funds covering the transactions to the acquiring bank. The ACH 
1% 10 function further sends transaction files to the ISOs or ACQs responsible for establishing 
*S the MAs with the merchants whose transactions are being cleared. The ISOs and ACQs 

uj 

^0 maintain risk management files which include underwriting and transaction approval 

H 

guidelines. If various transactions do not meet the transaction approval guidelines, the 
l2 ISO or ACQ withholds settlement of the transactions and prevents funds from being 

*£!■ 15 dispersed by the acquiring bank to the merchant unless or until a satisfactory 

Q 

H> determination that the transactions are legitimate has been made. If, however, the 
transactions do not run afoul of the transaction approval guidelines, the funds transfer is 
approved, and the acquiring bank transfers the funds to the merchant. Dispersing the 
funds to the merchant completes the settlement process. 
20 As can be seen from the above description, a large amount of data must pass 

between a number of different entities or sites during the course of the credit card 
transaction. Furthermore, there are large numbers of merchants processing transactions 
using different shopping cart software, vendor payment gateways, front-end processing 
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centers, back-end settlement networks, acquiring banks, issuing banks and ISOs or 
ACQs. All of these components and organizations must be properly identified and 
properly set up to identify and process transactions for each particular merchant such as 
merchant 12. Setting up the merchant with proper identification codes, and updating the 
5 payment gateway 16, the front-end systems 24, the back-end systems 26, the acquiring 
bank 28, and the ISO 20 or ACQ 21 with information identifying the merchant associated 
with the identification codes defined by a newly-created MA all take place when the MA 
is established. Identifying and assembling available active MID, TID and GID into a 
single account and updating the various systems with the new MID, TID, and GID 

ijl 10 assigned to a new MA is a primary reason for the delay in establishing new MAs. 

%I3 Another cause for delay in establishing new MAs is the hiatus in the rest of the 

w 

iS application process during the underwriting step wherein the merchant's bona fides are 

w 

established and confirmed, 
f* SUMMARY OF THE INVENTION 

Ha ait 

S 

SB! 

15 The present invention relates to a method for quickly and efficiently establishing 

5 

U merchant accounts (MAs) which allow on-line and conventionally operated companies to 

accept credit cards as payment over a computer network. For purposes of the present 
application the invention will be described as being carried out over the global computer 
network commonly referred to as the Internet. However, it should be noted that the 
20 present invention is not limited to embodiments carried out over the Internet; other 
computer networks, or combinations of networks, may alternatively be employed. The 
method of the present invention allows a merchant to begin processing transactions 
substantially immediately upon submitting an on-line merchant account application. The 
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present invention may be carried out using software code readily written by those skilled 
in the art to implement the various functions described herein. 

According to a preferred embodiment of the invention, an application processing 
entity, such as an independent sales organization (ISO) or an acquirer bank (ACQ), is 
5 responsible for establishing merchant accounts, including assigning to the merchant 
merchant identification numbers (MIDs), terminal identification numbers (TIDs) and 
gateway identification numbers (GIDs) to enable the merchant to process credit card 
transactions. This first processing entity (ISO or ACQ) is also responsible for updating 
the various systems involved in processing transactions and settling accounts for 
■^10 transactions subsequently entered by the merchant. 

^ According to a preferred method of the present invention, the application 

hi 

S processing entity maintains a database of active available MIDs, TIDs and GIDs. Upon 
\i receiving an indication from a merchant that the merchant desires to establish a new 

3 

{"* merchant account, the application processing entity transmits a merchant account 
^15 application to the merchant. The merchant then completes the form, preferably on-line, 
g and transmits the data requested on the form to the application processing entity. The 
application process is preferably controlled by a merchant account application network 
server operated by the application processing entity, and the resultant exchange of forms 
and data preferably takes place over the Internet. 
20 Once the application processing entity receives the merchant's completed 

application form, the application processing entity creates a new merchant account 
uniquely associated with the merchant. The new merchant account is populated by a 
series of shell accounts associating particular MIDs, TIDs and GIDs selected from a pool 
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of available active MIDs, TTDs and GIDs stored in the application processing entity's 
database. The MID, TID and GED assigned to the new merchant account (MA) are then 
sent to the merchant who can immediately use the MID, TID and GID assigned to it to 
process credit card transactions. The various credit card transaction processing systems 
over the Internet are also updated with the new MID, TID and GID assigned to the new 
MA. 

In an alternative embodiment of the invention (which may use API or XML), an 
individual MID, TID and GID would not be assigned to a single account prior to the 
assignment of these identification numbers to a particular merchant and the activation of 
the account. Rather, the MID, TID and GID would be assigned in real time or "on the 
fly" by pulling these identification numbers from another server such as a vendor or a 
private vendor gateway when the merchant submits an indication that it wishes to 
establish a new MA. 

Further, according to the inventive method of the present invention, upon creating 
the new merchant account, the application processing entity may set a divert flag in its 
own back-end systems. The divert flag acts to prevent the transfer of funds from an 
acquiring bank associated with the newly-created merchant account (MA) to the 
merchant in settlement of transactions processed by the merchant. The divert flag will 
remain set until the merchant's application completes the underwriting process in which 
the ISO determines whether the merchant represents an acceptable risk according to 
predefined conventional risk criteria. Since the merchant's MID, TED and GID are active, 
the merchant can process credit card transactions immediately, even though the 
merchant's application has not completed the underwriting process. However, the funds 
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associated with the credit card transactions processed by the merchant will not be 
dispersed to the merchant while the divert flag is set. 

When the application successfully completes the underwriting process, the divert 
flag may be reset and funds allowed to flow to the merchant to cover the diverted 
5 transactions. In this way, the merchant may begin accepting credit cards substantially 
immediately upon opening the merchant account, even while the underwriting process is 
taking place. At the same time, the application processing entity and the acquiring bank 
associated with the account are protected against releasing funds to a possibly 

f =; unscrupulous or fraudulent applicant until the merchant has passed the underwriting 

•.qIO process. 

y The method of the present invention further includes provisions for displaying a 

^ banner advertisement on the web site of a third party such as an application service 
■ provider providing web hosting services. Such a banner advertisement may include a 

[j hypertext link to a web site operated by the application processing entity (ISO or ACQ). 
H 15 Thus, a merchant viewing the web site of the third party may access the application 
processing entity's web site by mouse clicking the banner advertisement and executing 
the hypertext link to the web site. The hypertext link associated with the banner 
advertisement may include embedded or encoded data which identifies the party hosting 
the banner advertisement, so that the application processing entity may record how a 
20 merchant applicant was directed to the application processing entity's site. The 
application processing entity may then establish residual tables so that the party who 
directed the merchant to the application processing entity may share in the profits from 
servicing the merchant's account. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 is a block diagram of a system for processing credit card transactions over 
the Internet; 

Fig. 2 is a flowchart showing the method of the present invention; 

Fig. 3 is a block diagram of the ISO's back-end systems for implementing the 
method of the present invention; 

Fig. 4 is a flowchart showing the generation of an MA application employing the 
ISO's back-end systems depicted in Fig. 3; 

Fig. 5 is a flowchart of the steps required to establish the MA employing the ISO's 
back-end systems depicted in Fig. 3; 

Fig. 6 is a sample on-line MA application form; and 

Fig. 7 is a sample congratulation page wherein the MID, TED and GID of a new 
MA are transmitted to a new on-line MA applicant. 

DETAILED DESCRIPTION OF THE INVENTION 

The present invention provides an improved method which speeds up the process 
in which a merchant obtains an activated MA for processing credit card transactions. The 
method is carried out by an application processing entity such as an independent sales 
organization (ISO) or an acquirer bank (ACQ) responsible for establishing merchant 
accounts (MAs) and thereby establishing the relationship between merchants and an 
acquiring bank as described in the background section. Once this relationship has been 
established, the acquiring bank clears the merchant's transactions and disperses funds to 
the merchant to cover the credit card transactions entered by the merchant. The 
application processing entity acts as an agent of the acquiring bank and typically will 
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receive a fee from the acquiring bank based on a percentage of the value of the 
transactions processed by each merchant for which the application processing entity has 
established an MA. 

The method according to the present invention is set forth in the flowchart in Fig 
2. In this example, the application processing entity is an ISO. The method begins at 
step 40 where the ISO maintains a pool of MA identification numbers (MIDs), terminal 
identification numbers (TIDs), and gateway identification numbers (GIDs) that have been 
activated but not assigned to MAs. The ISO may organize the pool of available MIDs, 
TIDs and GIDs as a series of shell accounts wherein an individual MID, TID and GID is 
assigned to a single account prior to the account being assigned to a particular merchant 
and activated. Since the MID, TID and GID are all active ID numbers, they are 
immediately available for processing credit card transactions as soon as the shell account 
is assigned to a merchant. Next, step 42 of the inventive method involves receiving an 
indication from a merchant that the merchant wishes to establish a new MA. Such an 
indication may be registered in a number of different ways, including contacting the 
ISO's Internet web page. 

Upon receiving an indication that a merchant wishes to apply for a new MA, the 
ISO transmits an MA application to the merchant at step 44. Typically this will be 
accomplished by downloading the application from the ISO's web server to the merchant 
over the Internet. Once the merchant has received the MA application form, the 
merchant completes the form and sends it back to the ISO. Again, this transaction 
preferably will occur by way of the Internet. The ISO receives the completed application 
at step 46. At step 48 the ISO selects a shell account containing an available MID, TID 
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and GID from the pool of available active MIDs, TIDs and GIDs and transmits the MID, 
TID and GID contained in the shell account to the merchant. 

In an alternative embodiment of the invention (which may use API or XML), an 
individual MID, TID and GEO would not be assigned to a single account prior to the 
5 assignment of these identification numbers to a particular merchant and the activation of 
the account. Rather, the MID, TID and GID would be assigned in real time or "on the 
fly" by pulling these identification numbers from another server such as a vendor or a 
private vendor gateway when the merchant submits an indication that it wishes to 
establish a new MA. Now, at step 50 the ISO creates a record associating the merchant 

n 

10 applicant with the selected MID, TID and GID, and establishing an active MA. 
n Because the selected MID, TID and GID were either chosen from a pool of shell 

is! 7 

\D accounts made up of active MIDs, TIDs and GIDs or, in the alternative, chosen on the fly 

^ from available MIDs, TIDs and GIDs, the merchant may begin processing credit card 

\ A transactions substantially immediately upon receiving the MID, TID and GID now 

^ 15 associated with its MA. When the application completes the underwriting process, the 

%— I 

y, appropriate funds will flow to the merchant, as explained below. 

Upon establishing the new MA, the ISO system updates the other elements of the 
credit card processing system at step 52. This includes updating the front-end processing 
center, the Internet gateway identified in the GID, and the back-end systems including the 
20 acquiring bank's systems and issuing bank's systems with information regarding the 
identity of the merchant associated with the MA, and other demographic information 
relating to the merchant. 
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When the merchant's new MA account is initially set up, the ISO's internal 
systems set a divert flag in the ISO's risk files as indicated in step 54. The ISO's risk 
files are established to monitor transactions to identify suspicious and possibly fraudulent 
activity. If individual transactions, or transactions involving a particular merchant do not 
5 meet the ISO's risk guidelines, the ISO may withhold approval for transferring funds 
from the acquiring bank to the merchant. Further, according to the present invention, the 
ISO will withhold approval for the dispersal of funds to a merchant if the divert flag is set 
in the merchant's MA indicating that the merchant's account has not cleared the 
underwriting process. The diverted transactions are accumulated for later processing and 
1 0 the dispersal of funds to the merchant once the divert flag has been reset. 

1% At step 56 the ISO undertakes an underwriting process wherein the information 

iu 

In provided by the merchant in the on-line application form is reviewed. The ISO has 
predefined rules which determine whether or not a given merchant represents an 

5 

\ A acceptable risk for doing business with. This underwriting process may proceed in a 
¥ tl5 conventional manner with human control and intervention. Alternatively, it may be 
It automatically implemented by electronically submitting the pertinent data to a computer 
which is programmed to compare the data to predetermined standards and criteria and to 
render a creditworthiness decision. 

If, upon completion of the underwriting process, the merchant appears to be a 
20 legitimate business and the merchant's risk factors are acceptable, the ISO resets the 
divert flag at step 58, thereby allowing funds to flow from the acquiring bank to the 
merchant to cover the transactions entered by the merchant just as in traditional 
settlement transactions. This process protects the ISO and acquiring bank from 
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dispersing funds to unscrupulous applicants, while allowing merchants to begin 
processing credit card transactions immediately upon receiving the MA. Legitimate 
merchants will receive their funds generated from credit card transactions once the 
underwriting of their application is completed. 
5 A system for implementing a preferred embodiment of the invention will now be 

described with reference to Figs. 1, 2, 4, and 5. The overall set up of a system for 
carrying out the preferred embodiment of the inventive method of the present application 
is substantially the same as that shown in Fig. 1 and described in the background section. 
A merchant web server 12, a merchant host web server 14, an ISO web server 20, and a 
JtjlO payment gateway 16 are all connected to the Internet 22. The payment gateway 16 is 

% connected via a private network to a front-end processing center 24, which in turn is 

id 

connected to a back-end settlement network 26. The internal systems of the ISO, the 

SI 

% 4 acquiring bank, and the issuing bank are all interconnected via the back-end settlement 
network 26. 

*J 15 It is contemplated that a merchant desiring to establish an MA may approach the 

lI ISO either directly or through a merchant host web server 14. A merchant may contact 
the ISO directly by accessing the ISO's web page directly over the Internet. If, on the 
other hand, the merchant is establishing its web presence through the services of a 
merchant host, the merchant may be directed to the ISO's web page by clicking on a 
20 banner advertisement displayed on the merchant host's web page. 

It is expected that a plurality of merchant hosts will display the advertising banner 
for the ISO's services. Each merchant host web server will be provided with software for 
displaying the ISO's advertising banner on its web page. As a merchant steps through the 
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process of establishing an Internet storefront (or a bricks-and-mortar establishment) 
employing the merchant host's facilities, there may be a step in which the merchant is 
required to either supply information regarding its preexisting MA or establish a new one. 
At this juncture the ISO's banner advertisement may be displayed indicating that the MA 
may be applied for on-line. The banner advertisement appearing on the merchant host's 
web page will include a hypertext link which is executed by the merchant's web browser, 
causing the browser to contact the ISO's web server. The link further includes 
information such as an associate and representative code which allows the ISO to 
determine the merchant host from which the merchant contact originated. If the merchant 
clicks on the banner advertisement, the merchant's web browser contacts the ISO's web 
server and the ISO's web server downloads the ISO's web page to the merchant's web 
browser. 

Whether the merchant contacts the ISO directly or through a banner 
advertisement on a merchant host web site, the end result is that the ISO's MA 
application web page is downloaded to and displayed on the merchant's web browser. 
The merchant may then indicate that it wishes to establish a new MA by selecting the 
appropriate menu options on the ISO's MA application web page. Upon receiving such 
an indication, the ISO's MA application form is downloaded to the merchant's web 
browser for display. 

In addition to the basic components shown in Fig. 1, the ISO operates additional 
"back-end systems" as shown in Fig. 3. The ISO's systems include a web server 60 
connected to the Internet and to the back-end settlement network 26, and a central 
database server 62 connected to various processing vendors 64. The central database 
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server includes host application tables 66; applicant tables 68; issued MID, TID and GID 
tables; central database files 72; residual and profitability tables 74; agent tables 76; 
available MID, TID and GID tables 78; merchant tables 80; risk tables 82; shell account 
systems 84; and application files 86. In the alternative real-time approach to assigning 
MIDs, TIDs and GIDs, shell account system 84 would be replaced by real-time gateway 
83 and real-time activation front en&'back end 85. 

A flowchart for displaying a merchant application on a merchant's Internet web 
browser is shown in Fig. 4. At step 102, the merchant contacts the ISO's web server. At 
step 104 the ISO's web server determines whether the merchant contact originated from a 
merchant host displaying the ISO's advertising banner, or whether the merchant contacted 
the ISO's web site directly. This determination may be made by examining the link 
executed by the merchant's web browser in contacting the ISO's web server. 

If the merchant contacted the ISO's web server directly, the process moves to step 
106 wherein a "splash page" providing a step-by-step navigational site map or a full 
window containing instructions for completing the application is transmitted from the 
ISO's web server to the merchant for display by the merchant's web browser. The splash 
page provides information about the MA, pricing for services, and instructions for 
obtaining an MA. Because there is no third party involved, the splash page is populated 
by a default demographic, hierarchy, and default pricing parameters. Following step 106, 
the ISO's web server transmits a default on-line application to the merchant over the 
Internet for display by the merchant's Internet browser as indicated in step 108. 

Returning to step 104, if the merchant contact originated from a banner 
advertisement displayed by a merchant host, the system must then determine whether 
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there are any special demographic, hierarchy, or pricing parameters associated with the 
particular merchant host from which the contact arose, as indicated at step 110. If no 
special parameters have been established between the ISO and the merchant host, then 
the default splash page populated by the default demographic, hierarchy and pricing 
parameters is transmitted to the merchant for display by the merchant's Internet browser 
in step 106. Otherwise, if special arrangements have been made between the merchant 
host and the ISO, a unique splash page is transmitted to the merchant, as indicated at step 
112. This unique splash page will be populated by merchant host specific demographic, 
hierarchy, and pricing parameters retrieved from the host tables 66 which are accessed 
through the ISO's central database server 62. 

Next, at step 114 a determination is made as to whether there is a co-branding 
relationship between the merchant host and the ISO. Again, this can be determined by 
accessing the host application tables 66 via the ISO's central database server 62. If there 
is no co-branding relationship between the merchant host and the ISO, then the standard 
default on-line application is downloaded to the merchant at step 108. An example of a 
default merchant account application is shown in Fig. 6. If there is a co-branding 
relationship between the merchant host and the ISO, a merchant host specific co-branded 
online application (not shown) is sent to the merchant at step 116. Both the on-line 
application and the splash page are displayed by the merchant's web browser at step 118. 

Turning now to Fig 5, a flowchart showing the process of establishing a new MA 
is shown. Once the on-line application has been sent to the merchant, the merchant 
completes the form by typing in the information required by the various fields contained 
on the form and transmits it back to the ISO's web server 102. The ISO's web server 102 
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receives the completed application at step 120. At step 122 the ISO's central database 
server retrieves data identifying the merchant host, if any, from the agent tables 76 and 
posts the data to the applicant tables 68. Henceforth, the MA established for the 
merchant will be associated with the merchant host who directed the merchant to the ISO. 

At step 124 the ISO's central database server selects a shell account including an 
available MID, TID and GID from the MID, TID and GID tables 78. The MID, TID and 
GID associated with the shell account are written to the issued MID, TID and GID tables 
70 at step 126. This step includes creating and storing a record of the newly created MA 
including the MID, TID and GID and the merchant data obtained from the completed on- 
line MA application form. Substantially simultaneously, the MID, TID and GID may be 
sent to the merchant via the ISO's web server 60 over the Internet, as shown in step 130. 
Or, in the real-time alternative embodiment discussed above, no shell account is 
established, but rather the MID, TID and GID are assigned on the fly as at step 125. 

Fig. 7 shows a congratulatory page which may be transmitted to the merchant to 
be displayed by the merchant's web browser. The congratulatory page includes the 
merchant's MID, TID and GID. Also, a confirmation (not shown) may be sent to a 
separate e-mail account provided by the merchant during the application process. 

The ISO's central database files are updated at step 130. The ISO's risk 
management is updated at step 132 by re-examining risk data and/or by generating a 
credit report. For newly created MAs this involves setting a divert flag which will 
prevent funds from being disbursed from the acquiring bank associated with the MA to 
the merchant until the merchant's application has completed the ISO's underwriting 
process. At step 134 the ISO's residual and profitability tables are updated. These allow 
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the ISO to monitor the transactions processed by the merchant, and to track the profits 
which must be allocated to the merchant host who originally directed the merchant to the 
ISO. 

From the foregoing, it will be observed that numerous variations and 
modifications may be effected without departing from the spirit and scope of the 
invention. It is to be understood that no limitation with respect to the specific methods 
illustrated herein is intended or should be inferred. It is, of course, intended to cover by 
the appended claims all such modifications as fall within the scope of the claims. 
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